ETSITS122 115V11.6.0 



(2012-09) 




Digital cellular telecommunications system (Phase 2+); 
Universal Mobile Telecommunications System (UMTS); 

LTE; 

Service aspects; 

Charging and billing 

(3GPP TS 22.1 1 5 version 1 1 .6.0 Release 1 1 ) 



^ 



Advanced 



ibit^iii 



A filOBAL INITIATIVE 



3GPP TS 22.1 1 5 version 1 1 .6.0 Release 1 1 1 ETSI TS 1 22 1 1 5 V1 1 .6.0 (201 2-09) 



Reference 



RTS/TSGS-01 2211 5vb60 
Keywords 



GSM,LTE,UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2012. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS'^" and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 
2QppTM ^^^ LTETM are Trade Marks of ETSI registered for the benefit of its Members and 

of the 3GPP Organizational Partners. 
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 22.1 1 5 version 1 1 .6.0 Release 1 1 2 ETSI TS 1 22 1 1 5 V1 1 .6.0 (201 2-09) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 22.1 1 5 version 1 1 .6.0 Release 1 1 3 ETSI TS 1 22 1 1 5 V1 1 .6.0 (201 2-09) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 7 

4 Main Requirements and High Level Principles 7 

4.1 Cross Phase Compatibility 9 

4.2 Charging Entity Relationships 9 

4.3 Charging guidelines for IP-Multimedia services 11 

4.3.1 User Charging Requirements 11 

4.3.1.1 Session End Point Configurations 11 

4.3.1.2 Charging Principles For User Session Components 12 

4.3.1.3 Other Charging Requirements 14 

4.3.2 Roaming Charging Requirements 14 

4.3.3 Interconnect Charging Requirements 15 

4.3.4 Conveyance & Usage charging requirements 16 

4.3.5 Charging 3"* parties 16 

4.3.6 Advice of Charge (AoC) 16 

4.3.7 Service Aware Charging Requirements 17 

4.4 Additional Charging requirements for prepay services 17 

4.5 QoS and gating based on spending limit 18 

5 Collection of charging information 18 

5.1 Charging information Requirements 18 

5.1.1 Information provided by the user 18 

5.1.2 Information provided by the serving network 19 

5.1.3 Charged Party 20 

5.1.4 Information provided by the third party accessed by the user 20 

5.2 Special Cases 21 

5.2.1 Long calls and sessions 21 

5.2.2 Multimedia calls 21 

5.2.3 Service Change 21 

5.2.4 E-Commerce 21 

5.2.5 Volume Based Charging 21 

5.2.6 VAS 21 

5.2.7 Usage of IP Multimedia service 22 

5.2.8 LWLAN 22 

5.2.9 Charging for two( and multi)-phases services for IMS networks 22 

5.2.10 CSG charging requirements for UTRAN and E-UTRAN 22 

5.2.11 Inter-UE Transfer charging 22 

5.2.12 Selected IP Traffic Offload charging 22 

6 Transfer of Charging Information 23 

6.1 Integrity, Secrecy and Validation of Content and Receipt of Charging Information 23 

7 Accounting and Settlement 23 

7.1 Delegation of charging authority 23 

7.2 Fraud Control 23 

7.2.1 Fraud Control by the Home Environment 24 

7.2.2 Fraud Control by the Serving Network 24 

7.3 Cost Control 24 



£75/ 



3GPP TS 22.1 1 5 version 1 1 .6.0 Release 1 1 4 ETSI TS 1 22 1 1 5 V1 1 .6.0 (201 2-09) 

7.3.1 Cross Phase Compatibility 24 

7.4 Inter-network Settlement 24 

8 Automatic Roaming Agreements 25 

8.1 Routing the Registration Request 25 

8.2 Settlement of charges 25 

Annex A (informative) : Change history 26 

History 29 



£75/ 



3GPP TS 22.1 1 5 version 1 1 .6.0 Release 1 1 5 ETSI TS 1 22 1 1 5 V1 1 .6.0 (201 2-09) 



Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document describes the Service Aspects of charging and bilHng of the 3GPP System. 

The present document is not intended to dupHcate existing standards or standards being developed by other groups on 
these topics, and will reference these where appropriate. The present document will elaborate on the charging 
requirements described in the Charging Principles in 3GPP TS 22.101 Service Principles. It will allow the generation of 
accurate charging information to be used in the commercial and contractual relationships between the parties concerned. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPPTS 22.101 

[2] 3GPP TS 22.066 

[3] 3GPP TS 22.234 

interworking". 



"Service aspects; Service Principles". 

"Support of Mobile Number PortabiHty (MNP)". 

"Requirements for 3GPP system to wireless local area network (WLAN) 



[4] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications" 

[5] 3GPP TS 22.086: "Advice of Charge (AoC) supplementary services" 

[6] ETS 300 178: "Integrated Services Digital Network (ISDN); Advice of Charge: charging 

information at call set-up time (AOC-S) supplementary service; Service description" 

[7] ETS 300 179: "Integrated Services Digital Network (ISDN); Advice of Charge: charging 

information during the call (AOC-D) supplementary service; Service description" 

[8] ETS 300 180: "Integrated Services Digital Network (ISDN); Advice of Charge: charging 

information at the end of the call (AOC-E) supplementary service; Service description" 

[9] TS 183 047: "Telecommunications and Internet converged Services and Protocols for Advanced 

Networking (TISPAN); NGN IMS Supplementary Services; Advice Of Charge (AOC)" 

[10] TS 183 058: "Telecommunications and Internet Converged Services and Protocols for Advanced 

Networking (TISPAN); SIP Transfer of IP Multimedia Service Tariff Information;Protocol 
specification" 

[11] void 

[12] 3GPP TS 22.220, "Service requirements for Home NodeBs and Home eNodeBs" 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the definitions in [4] are supplemented by the following definitions: 

Prepay service: A prepay service allows a subscriber to pay in advance for the use of specific services, the prepay 
account may be updated each time the subscriber uses the services related to that account. 

Real time: Time, typically in number of seconds, to perform the on-line mechanism used for fraud control and cost 
control. 

Session: logical connection between parties involved in a packet switched based communication This term is used for 
IP connections rather than the term 'call' that is normally used for a connection over conventional (circuit switched) 

systems. 

Note: Information about charging is typically collected in Charging Data Records (CDR). 

Local Charging Zone (LCZ): A logical grouping of a number of cells, where a special tariff applies for a select group 
of users. A network may have a number of LCZs. A LCZ does not necessarily need to be aligned with an LA or RA, i.e. 
the border of LCZ may not be the border of an LA or RA. 

3.2 Abbreviations 

For the purposes of the present document the definition of abbreviations in [4] apply. 

4 IVIain Requirements and High Level Principles 

The main new requirements for 3GPP system charging and accounting are: 

- to provide charging information for all charges incurred and requiring settlement between the different 
commercial roles; 

to allow fraud control by the Home Environment and the Serving network; 

to allow cost control by the charged party; 

to provide at the beginning of a chargeable event an indication to the charged party (if involved in the chargeable 
event) of the charges to be levied for this event; 

to allow itemised billing for all services charged to each subscription, including voice and data calls, and services 
offered by home environments; 

to enable the Home environment to provide a Prepay Service and to enable the serving network to support that 
Prepay Service for the Home environment"s subscribers; 

to allow interconnect (inter-operator) charging including mobile/fixed operator to mobile/fixed operator (circuit 
switched & IP), and mobile/fixed operator to IP network provider; and mobile/fixed operator to I-WLAN 
operator; 

to allow Network operator to 3"* party supplier (e.g. Value Added Service Provider) charging; 

to provide details required for Customer Care purposes; 

to support the shared network architecture so that end users can be appropriately charged for their usage of the 
shared network, and network sharing partners can be allocated their share of the costs of the shared network 
resources. 

The high level principles that will guide the charging requirements are summarised as follows: 
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It shall be possible to charge separately for each type of medium used (e.g. voice, video, data) in a session and 
for each service used (e.g. voice call, streaming video, file download); 

It shall be possible to charge for different levels of QoS applied for and/or allocated during a session for each 
type of medium or service used; 

It shall be possible to charge each 'leg' of a session separately. This includes the incoming and outgoing legs and 
any forwarded/redirected legs. (Note: The legs mentioned here are logical legs, i.e. not necessarily identical to 
actual signal and traffic flow. Even though tromboning may be avoided by optimal routing, the operator should 
still be able to charge for the "virtual legs" of the call); 

It shall be possible to charge unsuccessful calls and sessions (e.g. for billing purposes, to provide the user a full 
documentation of his call attempts); 

The user can be charged according to the service used irrespective of the technology used to deliver it. (That is, 
the charge is not derived from whether 2G or 3G is used); 

The user can be charged according to the technology used to deliver a service. (That is, different charges can be 
applied on 2G and 3G); 

It shall be possible to charge a user according to the network resources used. For example, if a large bandwidth is 
required to use high quality video, the user could be charged accordingly. This is related to charging by QoS; 

It shall be possible to charge users flexibly for the use of extra resources (in at least the same network) for all 
legs of the call. For example, if a video component is added to a voice call the use of extra radio resource at both 
ends of the call could be paid for by each user in the call or totally by the initiating user; 

It shall be possible to suppress charging for certain types of connection e.g. when a customer receives tones or 
network announcements or during sessions such as automated pre-pay top-up; 

It shall be possible to apply different charging based on tariff information provided by a 3"* party. This tariff 
information may change during the use of the service (e.g. based on menu selection in a voice response menu). 
In this case the requirement applies both for customer-charging and interconnect-charging; 

It shall be possible for the home network to charge its customers while roaming in the same ways as when they 
are at home. For example, if duration based charging is used for charging for streaming music in the home 
network, then it shall be possible to apply the same principle when the user is roaming; 

It shall be possible for operators to have the option to apply charging mechanisms that are used in GSM/GPRS. 
For example for duration of a voice call, for the amount of data transmitted (eg for streaming, file download, 
browsing) and for an event (one-off charge); 

It shall be possible for a network operator to charge its users for activities while roaming so that the home 
network will get the capability to raise service charges depending on the roamed to network, e.g. because of inter 
operator charges for the use of service capabilities within the visited network which will in general depend on 
the serving network. The ability to supply all the necessary information for all the charging options will depend 
on the capability of the visited network. For service capabilities which are provided by the home network, 
however, it is required that the charging information is collected to allow to identify the serving network of the 
served subscriber; 

It shall be possible for charging to be applied based on location, presence, push services etc.; 

The network may provide information to the UE so that the UE is able to notify and indicate to the user the 
LCZs it is in. This allows the user to decide whether to accept/originate the service depending on the LCZs they 
are in; 

It shall be possible to charge using pre-pay, post-pay, advice of charge, 3"* party charging techniques; 

It shall be possible for the home network to apply different tariffs to national calls and short messages 
established/sent by their subscribers while roaming in their Home PLMN depending on whether or not the called 
subscriber"s Home PLMN equals the calling subscriber"s Home PLMN, rather than on the called subscriber"s 
MSISDN; 

NOTE: This distinction is necessary only in the case, where the called subscriber's MSISDN may have been 
ported by Mobile Number Portability. 
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For circuit switched interconnection only a capability is required to collect information regarding user rate and 
user protocol at the interconnection point so that e.g. the identification of CS video telephony at the 
interconnection point for inter-network accounting purposes becomes possible. 

These new requirements and principles will allow users more freedom to obtain service when roaming, whilst providing 
effective cost and credit control for the Home Environment and User. 



4.1 Cross Phase Compatibility 



Where possible (e.g. services already defined within earlier releases), the charging information collected shall be 
consistent with the information already provided 

It is envisaged that 3GPP system will evolve beyond this Release with the addition of a number of new requirements for 
charging and billing, for example with the addition of a number of new requirements for charging and billing; these are 
noted in the appropriate sections below. The technical standards for each release should be developed in such a way that 
it is possible and practical to introduce these requirements, ideally in a backward compatible manner. 

NOTE: When a change is introduced which affects the 3GPP technical standards, it is said to be 'backward 
compatible' if existing equipment can continue to operate and perform correctly with equipment that 
conforms to the new implementation. 

4.2 Charging Entity Relationships 

In the process of introduction of the all-IP technology there will be a mixture of different types of entities using 
different types of technology. 

The diagram below shows the different entities involved in charging and their relationships. 
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The types of entities and the relevant type of charging as shown on the diagram are as follows: 

Users: retail charged by Mobile Network Operator or 3"* Party Service Provider. 

3"" Party Service Providers: wholesale charged by Mobile Network Operator. 

Other telecommunications operators: interconnect charging between Mobile Network Operator and non-IP 
'circuit-switched' Network Operators for call traffic carried; usage charging between Mobile Network Operator and 
IP -based Network Operators for session traffic carried. 

Otlier mobile operators: roaming charging between these entities, this may require different mechanisms for IP- 
based types from the traditional 'circuit-switched' types. Also, where mobile operators need to pass traffic to one 
another, there will be interconnect charging for non-IP 'circuit switched' types; usage charging for IP-based types. 

I-WLAN operators: where I-WLAN operators need to pass traffic to mobile operators or mobile operators to I- 
WLAN operators, there may be roaming and usage charging, . 

IP backbone carriers: conveyance charging Mobile Network Operators for traffic carried. 

3"" Party content & application suppliers: supplier charging between Mobile Network Operators and Value 
Added Service Providers for information exchanged. 

3"" Party Portals: access charging between Mobile Network Operators and this entity. 

Internet: charge for capacity of connection between Mobile Network Operator and Internet. An Operator pays a 
provider for a connection based on capacity, e.g. annual charge for a 2Mbit/s 'pipe'. 
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4.3 Charging guidelines for IP-IVIultimedia services 
4.3.1 User Charging Requirements 

This section describes the options required for the charging of end users. The network operator could charge users 
directly (retail charging) or charge a 3'^'^ party service provider (wholesale charging). These requirements can therefore 
apply to retail and wholesale charging. Note that the word 'session' is used to describe the connection between a user 
and either another user or a service. This term is used for IP connections rather than the term 'call' that is normally used 
for a connection over conventional (circuit switched) systems. 

The various ways that users can establish sessions and the main components are described. Also, the required charging 
options are specified. 

4.3.1 .1 Session End Point Configurations 

A variety of different connection configurations are possible for IP multi-media independently of the components of the 
session being used. It should be possible to charge for the following types of sessions with the options identified. These 
charging options should be applicable to each medium separately. Note that not all the charging options need to be used 
and that some of the options can be used only if the particular party is using the resources of IMS: 

The table below lists some example session scenarios and describes some of the possible charging options for each 
scenario. The table does not list all possible session scenarios nor does it list all possible charging options for the 
scenarios. Rather, the intent of the table is to emphasize the numerous charging options that shall be supported by an IP 
Multimedia System due to the complexity of sessions possible. The charging options shall adequately account for all 
session resources used in order to enable the operators to apply flexible billing policies and to satisfy regional and/or 
national regulatory policies. 

In general, any session shall allow for the following charging options: 

• To apply the 'Calling Party Pays' charging principle; 

• A 3'^'' party to be charged for all or part of the session; 

• Split charging between any of the parties, including 3"^ parties; 

• Session setup and session resources to have different charging rules. Different rules would be applied for example, 
in a scenario where A calls an advertising number, say B. B could be a web-based toy advertisement number, for 
example. In this scenario, A could pay for the initiation fee (session setup), and B could pay for the session 
resource. 

• Any party can add another media to the current session in progress and any of the parties (not necessarily the one(s) 
being charged for the current session) can be charged for the additional media. For example, A calls B and A is 
paying for the audio; B adds a wireless video image to the call and pays for that portion. The individual resource 
set-up and usage should be separately identified. This supports the 'Calling Party Pays' model; 

• During an active session, media types can change (e.g. audio changed to data) and shall be charged for 
appropriately. It is thus necessary to be able to detect a change of media during a session so that different rating 
may be applied. 

It should also be noted that during a multi-party session, normally if the charged party drops off the session, all 
components being charged to that party should drop. But it is foreseeable to support a service option that allows the 
charged party to continue to be charged even if they drop off the session. The charging rules should support this option. 



£75/ 



3GPP TS 22.115 version 11.6.0 Release 11 



12 



ETSI TS 122 115 V1 1.6.0 (2012-09) 



No 


CONNECTION 


DESCRIPTION 


CHARGING OPTIONS REQUIRED 


1 


A sets up a session to B 


A simple connection between 2 
subscribers or a subscriber and a 
service (eg voicemail) 


A pays for the session set-up to B 
A pays for the session resource to B 
B pays for the session resource to A 


2 


A sets up a session to B 


A simple connection where B is a 'toll 
free' (800) type service 


B pays for the session set-up 

B pays for the session resource 

A pays for part of the session resource 

(i.e. allowing split charging between A & 

B) 


3 


A requests session with B, B 
redirects to C 


This is redirection. The connection 
path is not set up to B from A, instead 
A is told to set up a connection direct 
toC 


A pays for the session set-up to B 
A pays for the session resource to C 
C pays for the session resource to A 
A pays for the session resource as 
though it were to B and B pays for the 
session resource to C as though it came 
from B 


4 


A requests session with B, B 
forwards to C 


This Is normal forwarding as In GSM. 
The connection path is A to B"s home 
network and B"s home network to C 


A pays for the session set-up to B 
A pays for the session resource as 
though it were to B and B pays for the 
session resource to C. 


5 


A sets up sessions with 
multiple parties (Multi-party) 


Connections to multiple parties are 
initiated by A 


A pays for the set-up of each session 
A pays for each of the sessions resource 
to each of the called parties 
Each of the called parties pays for the 
session resource to A 


6 


A has a multi-party session 
where the individual parties 
set up the session to A 


The multiple parties in the session 
initiate the session to A 


Each party pays for the session set-up to 

A 

A pays for the session resource to the 

multiple parties 

The individual parties in the session each 

pay for the session resource to A 


7 


A is in a session with B, 
then puts B on hold to set up 
a session with C, then 
returns to B after dropping C 


A still has a connection to B while 
also in a session with C. The session 
with B continues after the session 
with C is terminated 


A pays for each of session set-ups to B 
and C 

A pays for the session resource to B & C 
B & C pay for the session resource to A 


8 


A is in a session with B then 
answers a session request 
from C while keeping B on 
hold 


A still has a connection to B while 
also in a session with C. The session 
with B continues after the session 
with C is terminated 


A pays for the session set-up to B 

C pays for the session set-up to A 

A pays for the session resource to B and 

C 

B & C pay for the session resource to A 


9 


A sets up a session with B 
who is roaming in another 
network 


The connection is made from A to 
B"s home network and then 
forwarded to B in the visited network. 
(Normal GSM mechanism) 
Alternatively, A is redirected directly 
to B in the visited network 


A pays for the session set-up to B 
A pays for the session resource as 
though it were to B in his home network 
and B pays for the session resource from 
his home network to the visited network 
A pays for the session resource to B in 
the visited network 
B pays for the session resource to A 



4.3.1.2 



Charging Principles For User Session Components 



A number of different components can comprise a session. These components may be added or dropped from an 
ongoing session by any participating party. These components should be individually identifiable for charging purposes. 

Generally, the party that adds a component should be responsible for the payment for the use of the component. 
However, it should also be possible to charge all users that need an increase in resource to handle the component. An 
example is 2 users in an audio session where one of the users upgrades the session to videophone session. Both users 
could be charged extra for the use of the video component as this requires extra resource at both ends. 

Possible components are: 

Voice 
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Audio (real time) 

Audio (streaming) 

Video (real-time) 

Video (streaming) 

Data (download/upload) 

Data interactive eg web browsing 

Messaging (SMS text type) 

E-mail 

Data stream (unspecified content) This is where the network operator acts as a 'bit-pipe' 

It shall be possible to charge for each of these components separately in a session with the options shown in the table 
below. 

It shall be possible for operators to be able to charge for individual components of sessions even if there is no 
identificable service. For example a proprietary codec may be used to set up an 'end-to-end' speech session where the 
network operator acts as a 'bit-pipe'. In this case, it should be possible for the operator to charge for this differentially. 
This type of component is called 'datastream' in the table below. 

It might not be possible to apply some of the charging mechanism and type options described below depending on the 
capability of the networks used. 



COMPONENT 


CHARGING MECHANISM OPTIONS 


CHARGING TYPE OPTIONS 


Voice 


Charging principles as described in 
section 4.3.1.1 


Charging by duration of session 

Charging by QoS requested and/or 

delivered 

One-off set-up charge 


Real time Audio and Video 


Charging principles as described in 
section 4.3.1.1 


Charging by duration of session 

Charging by QoS requested and/or 

delivered 

One-off set-up charge 


Streaming Audio and Video 


Charged to the initiator of the request 
Charged to the sender of the audio or 
video 


Charging by duration of session 
Charging by volume of data, optionally 
OoS-differentiated 
One-off set-up charge 


Data (upload or download) 


Charged to the initiator of the request 
Charged to the sender of the data 


Charging by duration of session 
Charging by volume of data, optionally 
OoS-differentiated 
One-off set-up charge 


Interactive Data 


Charged to the initiator of the session 


Charging by duration of session 
Charging by volume of data, optionally 
OoS-differentiated 
One-off set-up charge 


l\/lessaging (SMS text type) 


Charged to the initiator of the 

message 

Charged to the recipient of the 

message 


Charging by event (eg like SMS) 
Charging by volume of data 


Unspecified content (data stream) 


Charged to the initiator of the session 
Charged to all parties involved 


Charging by duration of session 
Charging by volume of data (sent & 
received), optionally OoS- 
differentiated 
One-off set-up charge 
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4.3.1.3 



other Charging Requirements 



The user will also be charged for additional activities while in a session, for example downloaded applications or 
information. The table below shows some of these requirements and the priority. [This section will need to be further 
developed.] 



CHARGING REQUIREMENT 


DESCRIPTION 


Downloaded items 


User is charged for a specific item downloaded eg a 
music file, video clip, application 


Location based services 


User is charged for receiving information on his location 
(charging based on accuracy as an option). This could be 
a stand-alone location query or linked to another service 


Content accessed or downloaded 


User is charged according to the value of the information. 
Eg weather information, share price or other financial 
information 


M-Commerce 


Electronic transactions to 3'° party suppliers of goods & 
services 


Use of portal or other site 


User is charged for any access to a portal or any other 
site. This could be a one-off charge or based on duration 
or data volume of the portal or site use 


APN and associated content 


User is charged for access to a specific APN and for the 
content associated. Requirements are for further study. 


Actual duration of rendered service 


User is charged (e.g. for premium rate services or hotline) 
based on the actual duration of the rendered service 



4.3.2 Roaming Charging Requirements 



It shall be possible for a network operator to charge its users for activities while roaming. It shall be possible for a 
network operator to charge its users while roaming using the same principles used while on the home network. The 
ability to supply all the necessary information for all the charging options will depend on the capability of the visited 
network. 

In addition, the network operators have to charge each other for the use of their networks by roaming users. The 
methods of charging between operators may be different from the methods used to charge the user. For example, a user 
may be charged by duration for voice sessions made while roaming but the home network may pay the visited network 
by volume of data used. 

Mechanisms used in today"s networks may also be applied e.g. Inter-Operator Tariff (lOT). 

The table below shows the types of charging principle that networks will require for roaming settlement and a priority 
for its provision. 
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ITEM 


CHARGING METHOD DESCRIPTION 


Charging for session use 


Sessions made by users while roaming charged 
according to the principles described in section 4.3.1.1, 
above. This includes duration and volume charging 


Downloaded items 


Items downloaded by the user while roaming from 
providers associated with the visited networl< are charged 
bacl< to the home network for onward charge to the user 


Location based services 


Location information provided by the visited networl< is 
charged bacl< to the home network for possible onward 
charge to the user. 


Content accessed or downloaded 


Information that is accessed by the user while roaming 
from providers associated with the visited network is 
charged according to its value by the visited network back 
to the home network for onward charge to the user. 


M-Commerce 


Charging requirements between visited and home 
networks for M-Commerce transactions made by a 
roaming user are for further study. 


Use of portal or other site 


The visited network may charge the home network for 
any access by the roaming user to a local portal or any 
other local site. This could be a one-off charge and/or 
based on duration or data volume of the portal or site use 


APN & associated content 


Charge by visited network to home network for access to 
a specific APN and for the content associated. 
Requirements are for further study. 



4.3.3 Interconnect Charging Requirements 

This clause applies (but is not limited) to the following interconnection scenarios: 
Interworking between two IMS-based networks 
Interworking between IMS-based networks and PSTN/ISDN 
Interworking between IMS-based networks and TISPAN NGN supporting PES 
IMS transit scenario 

The following charging requirements principles and guidelines shall apply for IMS when interconnected to other 

systems: 

Existing, legacy charging principles will need to be retained while there is a requirement to interwork with non- 
IP based 'circuit switched' type of networks 

All the charging and accounting information shall be collected as closest as possible to the interconnection point 
(subject to network element performance capabilities). 

A session or a service instance shall be uniquely identified within a network domain to allow a correct 
accounting and charging. 

The identities of the originating network and of the destination network shall be unique and transported at 
signalling layer. This applies also to transit scenarios. 

The interconnecting provider(s) will be able to apply Inter Operator Tariff schemes both for offline and online 
charging. 

Charging information will be available for recording at both ends of interconnected parties. The charging 
information shall be sufficient to enable inter operator accounting correlation and inter operator dispute 
resolution. 

The real-time transfer of tariff information in interconnection scenarios shall be supported when the serving 
network supports it, in order to support value added services that are billed by the caller's operator (e.g. Premium 
rate services 0900 or hotlines). 
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NOTE: Such services often appear as 3' party services where the tariff information resides in the called network 
and the caller"s operator does not have this information. 

This tariff information must be submitted by the external provider in realtime, so that the caller's operator is 
capable of 

- providing AoC (Advice of Charge) information to the caller. 

capturing the imported tariff information into charging records. 

The service-hosting network shall provide appropriate charging information to the caller" s operator in a secure way, 
independently from the realtime transfer of charging information for AoC purposes. 

NOTE: Where required to support offline charging for third party services where the tariff information resides in 
the called network and the caller's operator needs to bill the end user for that service. 

4.3.4 Conveyance & Usage charging requirements 

It shall be possible for network operators (including mobile, fixed and IP backbone suppliers) to charge each other for 
the use of resources required to support user sessions. The items to be charged and the principles to be applied are 
described below. 

The methods of charging between operators could be different from the methods used to charge the user. For example, 
a user may be charged by duration for voice sessions but the mobile network may pay the fixed network or 3"* party 
carrier by volume of data used. 



ITEM 


CHARGING METHOD DESCRIPTION 


Session use 


Charging according to tlie resources used by duration of 
session and/or by data volume 


Quality of Service 


Charging by QoS delivered to and from the other network 



4.3.5 Cinarging 3'^ parties 

It shall be possible for network operators and 3"* parties to charge each other for the use of their resources. Third parties 
include content and application providers and portals. 

The items that will be charged and the principles are described below: 



ITEM 


CHARGING METHOD DESCRIPTION 


Content accessed 


The 3"^ party charges the end user (via the network 
operator) for content accessed/downloaded 


Access to site 


The 3™ party is charged by the network operator for each 
'hit' by its users 


Location information 


The 3'^ party is charged by the network operator for 
information on the location of the user. Amount charged 
could depend on accuracy of location information. 


Presence information 


The 3'° party is charged by the network operator for 
presence information about the user. 


Pushed information 


The 3'° party is charged by the network operator for each 
message pushed to the user, eg advertisements 



4.3.6 Advice of CInarge (AoC) 

The Advice of Charge (AOC) supplementary service allows the served user to be informed of MMTel session related 
charging information. 

AoC information may occur as: 
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Advice of Charge for Information purposes (AoCI): This supplementary service provides the information to 
produce an estimate of the cost of the service used. This means that the displayed value and the cost of the 
service used (e.g. corresponding bill item) may differ. 

Advice of Charge for Charging purposes (AoCC): This supplementary service provides the means by which the 
UE may indicate the charge that will be made for the use of MMTel service (i.e. the cost of the service used.) 

AoC-information may be sent to the served user at the following phases of communication: 

Charging information at communication set-up time (AOC-S): When the AOC-S supplementary service is 
activated, the IMS shall provide the user with information about the charging rates at communication 
establishment. In addition, the IMS may inform the served user at the communication set-up time if a change in 
charging rates is to take place after the communication set-up. 

Charging information during the communication (AOC-D): After the AOC-D supplementary service is activated, 
the IMS shall provide the user with charging information for a communication during the active phase of this 
communication. The supplied charging information shall be provided as a rate of communication service (e.g. 
costs per minute) or as a cumulative charge incurred so far for the communication (i.e. charges recorded from the 
start of the communication and until the moment the charging information is sent to the served user), or as 
charging units. When the call is released, the network shall send the recorded charges for the communication to 
the served user. 

Charging information at the end of the communication (AOC-E): When the AOC-E supplementary service is 
activated, the network shall provide the served user with charging information indicating the recorded charges 
for a communication when this communication is released. 

Compatibility with existing, legacy AoC principles from both fixed and mobile networks shall be taken into account. 
This comprises (but is not limited to) the following requirements for AoC as specified in TS 22.086 [5], ETS 300 178 
[6], ETS 300 179 [7], ETS 300 180 [8], TS 183 047 [9] and TS 183 058 [10]. 

AoC shall be also supported for interconnection scenarios. 

4.3.7 Service Aware Charging Requirements 

Service Aware Charging provides the means to perform charging based on identified IMS communication service and 
the service in use. 

To facilitate service aware charging, the system shall support the possibility to identify the IMS communication service 
and the service in use in the charging and accounting data collection. 

To ensure that service aware charging can be provided when roaming, the home network shall have the possibility to 
provide the unequivocally identified IMS communication service to the visited network. 

4.4 Additional Cinarging requirements for prepay services 

A prepay service allows a subscriber to pay in advance for the use of specific services, the prepay account will be 
decreased each time the subscriber uses the services related to that account. 

In a multi-service environment like 3GPP system, a subscriber can have different prepay accounts for different kinds of 
services (e.g. internet access, m-commerce, infotainment, location based services etc.). 

In order to guarantee the use of the prepay services, the following general requirements shall be fulfilled: 

The prepay service shall check a subscriber"s prepay account for coverage of the requested service charges prior to 
execution of that service. 

All charging information related to a specific prepay account shall be prevented to the user when the prepay credit 
of that account is exhausted or expired. 

All the ongoing charging information related to a specific prepay account shall be immediately (within a few 
seconds) interrupted as soon as the prepay credit of that account exhausts or expires. 
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The prepay service shall decrease the prepay account each time the subscriber uses the services related to that 
account. 

It should be possible to support more than one prepay account for a user if needed. 

To guarantee a meaningful multi-prepay account concept, at least 2 different prepay accounts should be supported. 

4.5 QoS and gating based on spending limit 

When the subscriber spending limit has reached a pre-set limit, the system shall be able to trigger a QoS 
downgrade and/or restrict access to one, several or all IP services based on operator pre-defmed thresholds. 

NOTE: A spending limit is the usage limit (e.g. monetary, volume, duration) that a subscriber is allowed to 
consume. 

When the subscriber spending limit (e.g. monetary, volume, duration) has been increased, the system shall be 
able to modify resources (e.g. QoS, Bandwidth, access) to services accordingly. 

The home network shall be able to enforce the subscriber spending limits for a roaming subscriber without 
having dedicated support of the feature in the visited network. 

Additional signalling load should be minimized. 



5 Collection of charging information 

The standard shall support the collection and transfer of charging information in order to facilitate: 

interworking with Release 98 and earlier releases 

fraud management procedures; 

unsuccessful calls and sessions documentation (e.g. for billing purposes); 

Note: collection of charging information due to error in the signalling flows (e.g. incomplete or erroneus call 
setup) are not required; 

- detailed itemised billing 

allow for prepay charging 

Generally, the charging information collected shall support the high level principles in section 4 (above) and the 
requirements identified for inter-operator charging as elaborated by the GSM Association. The information listed 
below is the minimum requirement. 

5.1 Charging information Requirements 

Charging information shall be collected in the Serving Network to record chargeable User or Mobile Station activity 
and inter-carrier connections. Some of the information is provided by the user, other information is only available in the 
network element of the serving network. 

Depending on the type of charging information some of the data may not be available or might not be required. 

5.1 .1 Information provided by the user 

The user"s user equipment that is incurring the charge shall provide the following information to the serving network: 
User identity used for authentication; 
Home environment identity; 
Terminal Identity and Terminal Class; 
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Destination endpoint identifier for service requested (e.g. B number); 

Resource requested (e.g. bandwidth, connectionless); 

QoS parameters (e.g. maximum delay); 

IP Multimedia capability requested (e.g. media components). 

5.1 .2 Information provided by tine serving network 

The network serving the user shall provide the following information to the home environment: 

All of the information listed in section above (Information provided by the user); 

Serving network identity; 

Recording network element identity; 

Universal Time (UT) at which the service request was initiated; 

Universal Time (UT) at which resources were provided for the service; 

Universal Time (UT) at which the service execution was successfully completed; 

Universal Time (UT) at which the service execution was unsuccessfully completed; 

Local time of the serving cell when the service request was initiated for the originating or terminating UE. This 
could either be explicitly reported, or implicitly reported by providing three pieces of information: the UTC, the 
time zone offset from UTC, and an indication of daylight savings time; 

Cause for unsuccessful completion of the service execution. At least the following causes shall be included: 

-the terminating party does not respond; 

-communication rejected by the terminating party; 

-network determined terminating party busy; 

-network congestion; 

-terminating party non reachable (out of coverage, switched-off); 

-destination non reachable (non active address, non-existing address). 
Resource allocated to the user; 
Quantity of data transferred both to and from the user; 

- QoS provided to the user; 

Location of the user in the standard format used for 3GPP location based services (e.g. geographical 
co-ordinates. Cell ID); 

- Network determined PLMN ID and Cell ID; 

whether GSM Optimal Routing was applied; 

If IN or CAMEL services were applied, the service parameters and the actually used destination number and 
calling party number identification; 

Time duration covered by this charging information to an accuracy of at least 1 second; 

Unique identity of the chargeable event which allows the billing system to correlate all charging information 
belonging to the same chargeable event; 

Unique charging information identity (unique per network element in a period of about 100 days); 
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IP Multimedia capability provided to the user; 

VAS information; 

Identifier of third party accessed by the user; 

Presence Information; 

Service Identification (eg voice call, video call, data download etc); 

Supplementary Services used; 

Prepay account identifier and related information. 

5.1.3 Charged Party 

For subscription related chargeable events the charging information shall indicate the charged party, i.e. normally the 
calling party. As alternative it should be possible to apply reverse charging or to charge the event to a party not involved 
in the event itself (e.g. a company as VPN subscriber). It should be possible for multiple leg calls (e.g. forwarded, 
conference or roamed) to be charged to each party as if each leg was separately initiated. However, in certain types of 
call, the originating party may wish/be obliged to pay for other legs (e.g. SMS MO may also pay for the MT leg.). 

It shall be possible to change the chargeable party at the call set-up. 

In case of inter-network chargeable events, the charging information usually does not contain the charged party, but it 
can be derived from network configuration information contained in the charging event data.. 

For each party to be charged for a chargeable event or parts of it charging information shall be collected. 

5.1 .4 Information provided by tine third party accessed by the user 

Supply of Value Added Services, especially in IP based environment, is often made with the aid of third parties 
typically represented by portals and content/application providers. 

To execute an effective charging of these services, the following charging information should be provided by the third 
party: 

Third party identity; 

Type of service (information, entertainment, gaming, public utility); 

Change in the type of service provided to the user; 

Type of content (picture, videoclip, mp3 file, Java file); 

Universal Time (UT) at which the service request was initiated; 

If a service change happens. Universal Time (UT) at which the service provision was initiated; 

Universal Time (UT) at which the service execution was successfully completed; 

Universal Time (UT) at which the service execution was unsuccessfully completed; 

Cause for unsuccessful completion of the service execution. At least the following causes shall be included: 

-the terminating party does not respond; 

-communication rejected by the terminating party; 

-network determined terminating party busy; 

-network congestion; 

-terminating party non reachable (out of coverage, switched-off); 

-destination non reachable (non active address, non-existing address). 
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Cause for Abnormal reject of the service; 

Universal Time (UT) for abnormal reject of the service 

5.2 Special Cases 

5.2.1 Long calls and sessions 

The advent of packet data services, which can extend for very long periods of time (days, weeks etc), although at low 
cost because charges are based on data throughput, may mean that charging information are only output at the end of 
very long periods. For this reason the serving network shall support the transmission of charging information also 
during the life of the packet data session, either when some charge value is reached or some duration or some data 
volume or all three, to allow for both charging settlement and cost control. 

5.2.2 IVIultimedia calls 

During one call the user may invoke different services like speech, data transmission, video and audio, which may lead 
to a separate collection of charging information for each service in different network components. In this case, the 
billing system shall be able to correlate these charging information and to indicate to the user that they belonged to one 
call. 

5.2.3 Service Change 

Sufficient information about a service change using SCUDIF changing a voice call to a CS multimedia call, or vice 
versa, shall be collected to enable operators to apply maximum flexibility in charging. This information is collected on 
top of the data that is already available for the underlying call now subject for the service change. 

On a service change using SCUDIF the following information shall be collected on both sides of the call: 

1) Initiator of the service change (A side or B side) 

2) Type of the service change (To speech or to multimedia) 

3) For a service change to multimedia: nature of the service change (User or network initiated service change) 

5.2.4 E-Commerce 

The 3GPP system may be used to trade soft goods (e.g. information, video, audio), or hard goods (e.g. books) of high or 
low value per item between the user and a merchant. It shall be possible for such merchants to charge users directly for 
services they provide. Electronic payment mechanisms are or shall be made available through other standards 
(micropayment, credit card payment, etc), and therefore are outside the scope of this specification 3GPP shall not 
prohibit the use of these mechanisms, and, where possible, shall provide the basic communications transport to allow 
them to be used effectively. 

However, if the serving network acts as merchant of soft goods, it may charge the user directly, collecting the related 
charging information as described above or using micropayment mechanisms. 

5.2.5 Volume Based Charging 

It shall be possible to charge for the total volume of data/packets sent and received by the user. 

5.2.6 VAS 

It shall be possible to charge the user for Value Added Services offered by the network in terms of access, surfing, 
queries etc. irrespectively of the volume of data sent or received by the user. 
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5.2.7 Usage of IP Multimedia service 



It shall be possible to charge the usage of IP multimedia service independently of the volume of data sent or received 
by the user. Information on the IP Multimedia capability provided to the user (e.g. voice, mixture of voice and video 
component, numbers of parties) should be available in the charging information. 

5.2.8 I- WLAN 

I-WLAN charging issues are captured in 3GPP TS 22.234 [3]. 

5.2.9 Charging for two( and multi)-phases services for IMS networks 

It shall be possible to charge a service change in case of VAS that foresee different service phases at different tariffs. 
This applies both at the interconnection between IMS network operators and at the interconnection between IMS 
network operators and service providers. 

This information is collected on top of the data that is already available for the underlying communication now subject 
for the service change. 

5.2.1 CSG charging requirements for UTRAN and E-UTRAN 

Detailed requirements for CSG access may be found in 3GPP TS 22.220 [12]. 

Charging related requirements: 

It shall be possible to charge subscribers for consuming network services via a CSG cell based on the following 
information: 

- CSG identity of the CSG cell 

subscriber membership of the CSG 

type of service consumed by the subscriber 

addition to and deletion from a CSG 

An operator shall be able to provide applicable tariffing information when a subscriber is added to a CSG. 

The network operator shall be able to charge both on-line and off-line for subscribers consuming network 
services via a CSG cell. 

5.2.1 1 Inter-UE Transfer charging 

It shall be possible to charge for Inter-UE Transfer (i.e. transfer/replication/sharing) of media components across 
multiple IMS UEs . 

5.2.12 Selected I P Traffic Offload charging 

The network shall be able to apply volume-base charging to a subscriber regardless of whether the subscriber"s traffic 
has been offloaded from the mobile operator"s network as described in 3GPP TS 22.101 [1]. 

For subscribers" traffic offloaded from the mobile operator network, the network shall be able to apply either online or 
offline charging. 
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Transfer of Charging Information 



The efficient transfer of charging information between serving networks and from serving networks to home 
environments requires a standardised interface between these entities. It shall be possible to define different time 
intervals for the transfer of charging information between serving network and home environment (e.g. when a 
chargeable event occurs, when a chargeable event is initiated by the user, when a chargeable event terminates, at regular 
intervals during a chargeable event). 

The format of the charging information exchanged (see 5.1) shall be standardised. It shall be possible for the relevant 
parties to agree minimum and maximum age of charging information transferred between themselves. 

6.1 Integrity, Secrecy and Validation of Content and Receipt of 
Charging Information 

The transmission mechanism for charging information collected in 5.1 above shall ensure its integrity and secrecy. 

A mechanism to validate the source and integrity of the information shall be provided so that: 

the home environment shall be able to validate the source and integrity of the charging information supplied by 
the serving network; 

the serving network shall be able to validate the source and integrity of the charging information supplied by the 

user; 

the serving network shall have proof that services were provided to a specified user. 



Accounting and Settlement 



The serving network shall collect and process the charging data generated in its network elements. The record of each 
individual transaction shall be reported to the home environment at short time intervals in order to allow further 
processing by the billing system in the Home Environment, provide itemised bills, and to deal with any disputes 
regarding charges both for users and for other visited networks and home environment. 

The standard shall support the transfer of charging data at different intervals as required by the Home Environment (e.g. 
short time intervals, real time, other regular intervals). 

7.1 Delegation of charging authority 

The registration process allows the home environment to authenticate users before they incur any charges. Once 
authenticated, the home environment then delegates authority to the serving network operator with which he has a direct 
commercial relationship to incur charges for services supplied to that user. The direct commercial relationship may be 
with either the serving network operator if known directly by the home environment or a network operator known to the 
home environment. This procedure uses each network as trusted third parties in a chain of delegation between entities, 
thus allowing commercial transactions between entities who have no direct commercial dealings. There shall be an 
authentication procedure between all entities in the 3GPP system which have a commercial relationship. 

In the case of a multimedia telephony, when the HPLMN requests that optimal media routeing is not applied, the 
VPLMN shall disable optimal media routeing for all the subscribers of the requesting network. 

7.2 Fraud Control 

A mechanism to control fraud shall be provided by the serving networks and the home environment. 
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7.2.1 Fraud Control by the Home Environment 

Charging information shall be collected by the home environment in real time from all serving networks which its users 
are allowed to use. The billing system in the home environment shall process the information in real time and provide 
the means to set charge thresholds per time interval upon which some actions may be started, such as informing the 
customer care centre or even barring the user in the HLR. 

It shall be possible for the Home Environment to define different time intervals for the collection and the processing of 
charging information (e.g. real time, short time, other regular intervals). 

7.2.2 Fraud Control by the Serving Network 

Charging information shall be collected from the network elements and processed in real time. This will allow the 
serving network to always be aware of the exposure to visitors. A limit for the accumulated charges for all visitors from 
one home environment or a limit per visitor may be agreed between the home environment and the serving network. 

It shall be possible for the Serving Network to define different time intervals for the collection and the processing of 
charging information (e.g. real time, short time, other regular intervals). 

7.3 Cost Control 

A mechanism shall be standardised providing an indication to the user (if involved in the chargeable event) of the 
charges to be levied for a chargeable event. This mechanism shall be able to handle all possible charging scenarios, and 
all service and tariff variants that the home environment and the serving network may offer to the user. 

The user shall be able to set in his home environment a limit for the accumulated charges per time interval. Upon 
exceeding this limit or prior to incurring a charge which would exceed the limit, certain actions may be desired by the 
user: 

• notification to the user, requesting to extend the limit; or 

• Home Environment barring allowing no further originating calls; or 

• Home Environment barring cancelling the roaming permission. 

7.3.1 Cross Phase Compatibility 

For Release 99 the cost control mechanism may be based on Advice of Charge. However the Release 99 standards 
should not prevent the future implementation of the full Cost Control requirements. 

The Release 99 standards should allow these new features to be introduced in a backward compatible manner; 
specifically terminals conforming to Release 99 standards should continue to support the Release 99 service 
requirements when operating with future implementations of Advice of Charge in the Home Environment. 

7.4 Inter-network Settlement 

Mechanisms shall also be provided to allow inter-network settlement of charges on a bulk basis. The same mechanisms 
shall be used between home environments and serving networks. This will allow each of these parties to meter the total 
input and output of charges and thus determine the payments required on a periodic basis between each of the parties 
with which they directly interact. The mechanisms used shall allow each of the parties to meter charge flows 
independently, with the aim of matching the values recorded at both sides of the same interface. The imbalance in 
charge flow shall be accumulated in short time, such that each entity can be informed when a threshold has been 
exceeded and determine whether to continue. 
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8 Automatic Roaming Agreements 

Support for the requirements in this section is not required in Release 99. However the Release 99 standards should not 
prevent the future implementation of this requirement in a backward compatible manner (eg a roaming broker enabled 
Home Environment should inter-operate with a R99 Serving Network). 

It is a requirement that users shall be able to obtain service and use chargeable services with networks with whom 
neither they nor their home environment have any direct commercial agreement. This shall be enabled by interworking 
via trusted third parties. Each Home Environment shall interwork with one or more serving network operators, with 
whom they would negotiate a commercial roaming agreement and test the interworking. Any user wishing to use the 
services of a particular serving network would register with that serving network, that would either directly or indirectly 
interwork with the home environment. Fraud and cost control mechanisms shall be used to ensure that charges incurred 
for 3GPP services do not exceed the credit limits set. This can be applied for the user and the other roles involved in 
commercial dealings. In practice, any serving network shall be capable of operating as a roaming broker. 
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Figure 1 : Registration and Roaming Process 



8.1 Routing the Registration Request 

The same mechanisms used for routing calls and resolving addresses shall be used to route the subscription identity 
back to its Home Environment. The standard shall support a routing identification mechanism to allow a serving 
network, which does not maintain its own list of all known HE, to determine the appropriate route to reach a given HE. 
A number of alternative routes may be possible, and ideally the system should be capable of determining the lowest cost 
to the end user. 

Typically, smaller networks will only have a limited number of external connections to other networks or clearing 
houses, but may not know which one to use for an unknown (new) HE. In this case, the serving network may make a 
number of inquiries for each route to determine the lowest cost route to handle the call. 



8.2 Settlement of charges 



Settlement of charges incurred by a user shall be on a wholesale basis between the different parties involved in the 
registration link. By authorising a user to register, or a roaming broker to pass that on, each party is in turn authorising 
charges up to a maximum credit limit with the adjacent party. Any charges levied can then be paid to the adjacent party 
on a wholesale basis at the end of a mutually agreed accounting period. Funds are thus passed between each party for 
the services supplied by the network operator in a serial fashion. 
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